<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Logfile audit output | ElasticSearch 7.7 权威指南中文版</title>
	<meta name="keywords" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <meta name="description" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
	<script>
	var _link = 'audit-log-output.html';
    </script>
</head>
<body>
<div class="main-container">
    <section id="content">
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.7/audit-log-output.html" rel="nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/7.7/audit-log-output.html</a>, 原文档版权归 www.elastic.co 所有<br/>本地英文版地址: <a href="../en/audit-log-output.html" rel="nofollow" target="_blank">../en/audit-log-output.html</a></div>
                        <!-- start body -->
                  <div class="page_header">
<strong>重要</strong>: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html" rel="nofollow">当前版本文档</a>。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="secure-cluster.html">Secure a cluster</a></span>
»
<span class="breadcrumb-link"><a href="enable-audit-logging.html">Enabling audit logging</a></span>
»
<span class="breadcrumb-node">Logfile audit output</span>
</div>
<div class="navheader">
<span class="prev">
<a href="audit-event-types.html">« Audit event types</a>
</span>
<span class="next">
<a href="auditing-search-queries.html">Auditing search queries »</a>
</span>
</div>
<div class="section xpack">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="audit-log-output"></a>Logfile audit output<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/auditing/output-logfile.asciidoc">edit</a><a class="xpack_tag" href="https://www.elastic.co/subscriptions"></a>
</h2>
</div></div></div>
<p>The <code class="literal">logfile</code> audit output is the default output for auditing. It writes data to
the <code class="literal">&lt;clustername&gt;_audit.json</code> file in the logs directory. To maintain
compatibility with releases prior to 6.5.0, a <code class="literal">&lt;clustername&gt;_access.log</code> file
is also generated. They differ in the output format but the contents
are similar. For systems that are not ingesting the audit file for search or
analytics it is strongly recommended to keep only the newer format.</p>
<p>To turn off the deprecated output format, you can disable the logger in the
<code class="literal">log4j2.properties</code> file:</p>
<div class="pre_wrapper lang-properties">
<pre class="programlisting prettyprint lang-properties"># change info to off
# logger.xpack_security_audit_deprecated_logfile.level = info
logger.xpack_security_audit_deprecated_logfile.level = off</pre>
</div>
<p>Alternatively, use the
<a href="cluster-update-settings.html" class="ulink" target="_top">cluster update settings API</a> to dynamically
configure the logger:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.xpack.security.audit.logfile.DeprecatedLoggingAuditTrail": "off"
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1261.console"></div>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>If you overwrite the <code class="literal">log4j2.properties</code> and do not specify appenders for
any of the audit trails, audit events are forwarded to the root appender, which
by default points to the <code class="literal">elasticsearch.log</code> file.</p>
</div>
</div>
<h3>
<a id="audit-log-entry-format"></a>Log entry format<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/auditing/output-logfile.asciidoc">edit</a>
</h3>
<p>The log entries in the <code class="literal">&lt;clustername&gt;_audit.json</code> file have the following format:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Each log entry is a one line JSON document and each one is printed on a separate line.
</li>
<li class="listitem">
The fields of a log entry are ordered. However, if a field does not have a value it
will not be printed. The precise line pattern, together with the complete field
order, are specified in the <code class="literal">log4j2.properties</code> config file.
</li>
<li class="listitem">
The log entry does not contain nested inner JSON objects, i.e. the doc is flat.
</li>
<li class="listitem">
The field names follow a dotted notation to flatten inner objects.
</li>
<li class="listitem">
A field’s value can be a string, a number or an array of strings.
</li>
<li class="listitem">
A field’s value, a request body as well, will be escaped as per the JSON RFC 4627.
</li>
</ul>
</div>
<p>There is a list of <a class="xref" href="audit-event-types.html" title="Audit event types">audit event types</a> specifying the
set of fields for each sog entry type.</p>
<h3>
<a id="deprecated-audit-log-entry-format"></a>Deprecated log entry format<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/auditing/output-logfile.asciidoc">edit</a>
</h3>
<p>The log entries in the <code class="literal">&lt;clustername&gt;_access.log</code> file have the following format:</p>
<div class="pre_wrapper lang-txt">
<pre class="programlisting prettyprint lang-txt">[&lt;timestamp&gt;] [&lt;local_node_info&gt;] [&lt;layer&gt;] [&lt;entry_type&gt;] &lt;attribute_list&gt;</pre>
</div>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
<code class="literal">&lt;timestamp&gt;</code>
</span>
</dt>
<dd>
When the event occurred. You can configure the
timestamp format in <code class="literal">log4j2.properties</code>.
</dd>
<dt>
<span class="term">
<code class="literal">&lt;local_node_info&gt;</code>
</span>
</dt>
<dd>
Information about the local node that generated
the log entry. You can control what node information
is included by configuring the
<a href="auditing-settings.html#node-audit-settings" class="ulink" target="_top">local node info settings</a>.
</dd>
<dt>
<span class="term">
<code class="literal">&lt;layer&gt;</code>
</span>
</dt>
<dd>
The layer from which this event originated:
<code class="literal">rest</code>, <code class="literal">transport</code> or <code class="literal">ip_filter</code>.
</dd>
<dt>
<span class="term">
<code class="literal">&lt;entry_type&gt;</code>
</span>
</dt>
<dd>
The type of event that occurred: <code class="literal">anonymous_access_denied</code>,
<code class="literal">authentication_failed</code>, <code class="literal">access_denied</code>, <code class="literal">access_granted</code>,
<code class="literal">connection_granted</code>, <code class="literal">connection_denied</code>.
</dd>
<dt>
<span class="term">
<code class="literal">&lt;attribute_list&gt;</code>
</span>
</dt>
<dd>
A comma-separated list of key-value pairs that contain
data pertaining to the event. Formatted as
<code class="literal">attr1=[val1], attr2=[val2]</code>. See <a class="xref" href="audit-event-types.html#audit-event-attributes" title="Audit event attributes">Audit Entry Attributes</a> for the attributes that can be included
for each type of event.
</dd>
</dl>
</div>
<h3>
<a id="audit-log-settings"></a>Logfile output settings<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/auditing/output-logfile.asciidoc">edit</a>
</h3>
<p>The events and some other information about what gets logged can be
controlled using settings in the <code class="literal">elasticsearch.yml</code> file. See
<a href="auditing-settings.html#event-audit-settings" class="ulink" target="_top">Audited Event Settings</a> and
<a href="auditing-settings.html#node-audit-settings" class="ulink" target="_top">Local Node Info Settings</a>.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>No filtering is performed when auditing, so sensitive data may be
audited in plain text when including the request body in audit events.</p>
</div>
</div>
<p><a id="logging-file"></a>You can also configure how the logfile is written in the <code class="literal">log4j2.properties</code>
file located in <code class="literal">ES_PATH_CONF</code>. By default, audit information is appended to the
<code class="literal">&lt;clustername&gt;_audit.json</code> file located in the standard Elasticsearch <code class="literal">logs</code> directory
(typically located at <code class="literal">$ES_HOME/logs</code>). The file rolls over on a daily basis.
The deprecated logfile audit format (<code class="literal">&lt;clustername&gt;_access.log</code>) can be disabled
from the same <code class="literal">log4j2.properties</code> file (hint: look for the comment
instructing to set the log level to <code class="literal">off</code>). The deprecated format is a duplication
of information that is in place to assure backwards compatibility. If you are
not strict about the audit format it is strongly recommended to only use the
<code class="literal">&lt;clustername&gt;_audit.json</code> log appender.</p>
<h3>
<a id="audit-log-ignore-policy"></a>Logfile audit events ignore policies<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/auditing/output-logfile.asciidoc">edit</a>
</h3>
<p>The comprehensive audit trail is necessary to ensure accountability. It offers tremendous
value during incident response and can even be required for demonstrating compliance.</p>
<p>The drawback of an audited system is represented by the inevitable performance penalty incurred.
In all truth, the audit trail spends <em>I/O ops</em> that are not available anymore for the user’s queries.
Sometimes the verbosity of the audit trail may become a problem that the event type restrictions,
<a class="xref" href="audit-log-output.html#audit-log-settings" title="Logfile output settings">defined by <code class="literal">include</code> and <code class="literal">exclude</code></a>, will not alleviate.</p>
<p><span class="strong strong"><strong>Audit events ignore policies</strong></span> are a finer way to tune the verbosity of the audit trail.
These policies define rules that match audit events which will be <em>ignored</em> (read as: not printed).
Rules match on the values of attributes of audit events and complement the <a class="xref" href="audit-log-output.html#audit-log-settings" title="Logfile output settings">include/exclude</a> method.
Imagine the corpus of audit events and the policies chopping off unwanted events.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>When utilizing audit events ignore policies you are acknowledging potential
accountability gaps that could render illegitimate actions undetectable.
Please take time to review these policies whenever your system architecture changes.</p>
</div>
</div>
<p>A policy is a named set of filter rules. Each filter rule applies to a single event attribute,
one of the <code class="literal">users</code>, <code class="literal">realms</code>, <code class="literal">roles</code> or <code class="literal">indices</code> attributes. The filter rule defines
a list of <a href="regexp-syntax.html" class="ulink" target="_top">Lucene regexp</a>, <span class="strong strong"><strong>any</strong></span> of which has to match the value of the audit
event attribute for the rule to match.
A policy matches an event if <span class="strong strong"><strong>all</strong></span> the rules comprising it match the event.
An audit event is ignored, therefore not printed, if it matches <span class="strong strong"><strong>any</strong></span> policy. All other
non-matching events are printed as usual.</p>
<p>All policies are defined under the <code class="literal">xpack.security.audit.logfile.events.ignore_filters</code>
settings namespace. For example, the following policy named <em>example1</em> matches
events from the <em>kibana</em> or <em>admin_user</em> principals <span class="strong strong"><strong>and</strong></span> operating over indices of the
wildcard form <em>app-logs*</em>:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.audit.logfile.events.ignore_filters:
  example1:
    users: ["kibana", "admin_user"]
    indices: ["app-logs*"]</pre>
</div>
<p>An audit event generated by the <em>kibana</em> user and operating over multiple indices
, some of which do not match the indices wildcard, will not match.
As expected, operations generated by all other users (even operating only on indices that
match the <em>indices</em> filter) will not match this policy either.</p>
<p>Audit events of different types may have <a class="xref" href="audit-event-types.html#audit-event-attributes" title="Audit event attributes">different attributes</a>.
If an event does not contain an attribute for which some policy defines filters, the
event will not match the policy.
For example, the following policy named <em>example2</em>, will never match <code class="literal">authentication_success</code> or
<code class="literal">authentication_failed</code> events, irrespective of the user’s roles, because these
event schemas do not contain the <code class="literal">role</code> attribute:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.audit.logfile.events.ignore_filters:
  example2:
    roles: ["admin", "ops_admin_*"]</pre>
</div>
<p>Likewise, any events of users with multiple roles, some of which do not match the
regexps will not match this policy.</p>
<p>For completeness, although practical use cases should be sparse, a filter can match
a missing attribute of an event, using the empty string ("") or the empty list ([]).
For example, the following policy will match events that do not have the <code class="literal">indices</code>
attribute (<code class="literal">anonymous_access_denied</code>, <code class="literal">authentication_success</code> and other types) as well
as events over the <em>next</em> index.</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.audit.logfile.events.ignore_filters:
  example3:
    indices: ["next", ""]</pre>
</div>
</div>
<div class="navfooter">
<span class="prev">
<a href="audit-event-types.html">« Audit event types</a>
</span>
<span class="next">
<a href="auditing-search-queries.html">Auditing search queries »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>